From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0002.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0003.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0001.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0001.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0004.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0003.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0002.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0005.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0004.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0003.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0006.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0005.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0004.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment.html From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0007.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0006.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0005.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0001.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0008.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0007.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0006.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0002.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0009.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0008.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0007.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0003.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0010.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0009.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0008.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0004.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0011.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0010.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0009.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0006.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0012.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0011.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0010.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0007.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0013.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0012.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0011.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0008.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0014.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0013.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0012.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0009.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0015.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0014.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0013.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0010.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0016.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0015.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0014.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0011.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0017.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0016.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0015.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0012.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0018.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0017.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0016.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0013.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0019.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0018.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0017.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0014.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0020.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0019.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0018.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0015.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0021.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0020.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0019.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0016.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0022.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0021.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0020.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0017.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0023.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0022.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0021.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0018.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0024.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0023.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0022.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0019.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0025.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0024.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0023.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0020.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0026.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0025.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0024.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0021.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0027.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0026.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0025.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0022.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0028.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0027.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0026.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0023.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0029.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0028.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0027.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0024.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0030.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0029.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0028.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0025.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0031.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0030.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0029.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0026.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0032.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0031.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0030.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0027.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0033.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0032.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0031.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0028.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0034.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0033.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0032.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0029.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0035.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0034.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0033.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0030.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0036.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0035.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0034.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0031.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0037.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0036.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0035.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0032.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0038.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0037.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0036.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0033.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0039.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0038.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0037.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0034.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0040.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0039.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0038.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0035.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0041.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0040.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0039.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0036.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0042.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0041.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0040.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0037.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0043.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0042.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0041.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0038.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0044.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0043.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0042.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0039.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0045.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0044.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0043.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0040.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0046.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0045.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0044.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0041.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0047.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0046.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0045.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0042.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0048.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0047.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0046.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0043.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0049.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0048.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0047.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0044.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0050.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0049.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0048.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0045.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0051.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0050.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0049.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0046.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0052.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0051.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0050.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0047.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0053.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0052.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0051.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0048.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0054.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0053.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0052.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0049.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0055.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0054.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0053.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0050.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0056.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0055.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0054.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0051.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0057.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0056.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0055.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0052.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0058.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0057.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0056.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0053.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0059.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0058.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0057.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0054.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0060.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0059.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0058.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0055.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0061.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0060.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0059.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0056.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0062.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0061.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0060.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0057.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0063.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0062.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0061.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0058.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0064.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0063.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0062.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0059.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0065.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0064.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0063.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0060.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0066.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0065.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0064.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0061.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0067.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0066.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0065.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0062.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0068.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0067.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0066.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0063.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0069.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0068.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0067.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0064.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0070.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0069.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can skip the following step: > > Hi Joachim > > With regards to the above, I have not seen that we have Sun's OK to > promote that. I'm not very comfortable with the distribution > documentation advocating this without Sun agreeing. > > I see your point but I'd rather not actively promote putting > classes in > Sun's namespace without permission if you don't mind. This isn't > about > what is in a license. > > I'll go through the code tomorrow night. It was a late night at work > today. There is also a w32 fix comming for people opening and closing > multiple ports. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Jun 21 02:03:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 10:03:33 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: See System.load(String) [it's also mentioned under the URL you posted]. Regards, Joachim On 20.06.2006, at 18:23, Brian Schlining wrote: > So how do you use it to dynamically load a native lib? I've read > that you can't really modify the java.library.path after the JVM > has been launched. (http://forum.java.sun.com/thread.jspa? > threadID=627890&tstart=90) > > Thanks > > Brian Schlining > Software Engineer > http://www.mbari.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From baris.ozkan at elikasu.com.tr Wed Jun 21 07:58:06 2006 From: baris.ozkan at elikasu.com.tr (Baris) Date: Wed, 21 Jun 2006 16:58:06 +0300 Subject: [Rxtx] RS 232 ..additional parameters Message-ID: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Hi, Currently i am developing an application that requires to connect to a remote rs232 device through a dialup connection. My problem is that the communication needs several more connection parameters (i extracted that information from the vendor's dll , listed at the end of the message) I explored rxtx API and src files and could not find methods to set a majority of the parameters. Am i missing any point or does rxtx is limited to soem standard set of functionality(e.g. commAPI)? How is it possible ,if i want to put some extensions(???) to current rxtx implementation? I am not very good at rs232 programming so excuse me if this message is boring one. Thanx Baris Ozkan A Listing of Parameters: typedef struct _DCB { DWORD DCBlength; /* sizeof(DCB) */ DWORD BaudRate; /* Baudrate at which running */ DWORD fBinary: 1; /* Binary Mode (skip EOF check) */ DWORD fParity: 1; /* Enable parity checking */ DWORD fOutxCtsFlow:1; /* CTS handshaking on output */ DWORD fOutxDsrFlow:1; /* DSR handshaking on output */ DWORD fDtrControl:2; /* DTR Flow control */ DWORD fDsrSensitivity:1; /* DSR Sensitivity */ DWORD fTXContinueOnXoff: 1; /* Continue TX when Xoff sent */ DWORD fOutX: 1; /* Enable output X-ON/X-OFF */ DWORD fInX: 1; /* Enable input X-ON/X-OFF */ DWORD fErrorChar: 1; /* Enable Err Replacement */ DWORD fNull: 1; /* Enable Null stripping */ DWORD fRtsControl:2; /* Rts Flow control */ DWORD fAbortOnError:1; /* Abort all reads and writes on Error */ DWORD fDummy2:17; /* Reserved */ WORD wReserved; /* Not currently used */ WORD XonLim; /* Transmit X-ON threshold */ WORD XoffLim; /* Transmit X-OFF threshold */ BYTE ByteSize; /* Number of bits/byte, 4-8 */ BYTE Parity; /* 0-4=None,Odd,Even,Mark,Space */ BYTE StopBits; /* 0,1,2 = 1, 1.5, 2 */ char XonChar; /* Tx and Rx X-ON character */ char XoffChar; /* Tx and Rx X-OFF character */ char ErrorChar; /* Error replacement char */ char EofChar; /* End of Input character */ char EvtChar; /* Received Event character */ WORD wReserved1; /* Fill for now. */ } DCB, *LPDCB; typedef struct _COMMTIMEOUTS { DWORD ReadIntervalTimeout; /* Maximum time between read chars. */ DWORD ReadTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD ReadTotalTimeoutConstant; /* Constant in milliseconds. */ DWORD WriteTotalTimeoutMultiplier; /* Multiplier of characters. */ DWORD WriteTotalTimeoutConstant; /* Constant in milliseconds. */ } COMMTIMEOUTS,*LPCOMMTIMEOUTS; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fOutxCtsFlow = FALSE; dcb.fBinary = TRUE; dcb.fRtsControl = RTS_CONTROL_ENABLE; SetCommState(hComm , &dcb ); COMMTIMEOUTS commTimeOut; GetCommTimeouts(hComm, &commTimeOut ); commTimeOut.WriteTotalTimeoutMultiplier = 1; commTimeOut.WriteTotalTimeoutConstant = 18; // commTimeOut.ReadIntervalTimeout = 28; commTimeOut.ReadIntervalTimeout = 0; // commTimeOut.ReadTotalTimeoutMultiplier = 184; commTimeOut.ReadTotalTimeoutMultiplier = 300; // commTimeOut.ReadTotalTimeoutConstant = 1200; commTimeOut.ReadTotalTimeoutConstant = 1200; SetCommTimeouts(hComm, &commTimeOut); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060621/cc0ac49d/attachment-0068.html From ajmas at sympatico.ca Wed Jun 21 08:14:26 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 10:14:26 -0400 Subject: [Rxtx] When is 2.18 planned for? Message-ID: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Just curious as to know if there is a target date for 2.18? Andre From brian at mbari.org Wed Jun 21 09:36:00 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 21 Jun 2006 08:36:00 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Message-ID: Ha!! I suppose I should read my own postings. ;-) Thanks B On Jun 21, 2006, at 1:03 AM, Joachim Buechse wrote: > See System.load(String) [it's also mentioned under the URL you > posted]. > > Regards, > Joachim > > > On 20.06.2006, at 18:23, Brian Schlining wrote: > >> So how do you use it to dynamically load a native lib? I've read >> that you can't really modify the java.library.path after the JVM >> has been launched. (http://forum.java.sun.com/thread.jspa? >> threadID=627890&tstart=90) Brian Schlining Software Engineer http://www.mbari.org From ajmas at sympatico.ca Wed Jun 21 16:41:28 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 21 Jun 2006 18:41:28 -0400 Subject: [Rxtx] CVS build question Message-ID: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Is the CVS repository meant to build for gnu.io or javax.comm? I ask this, because I see the following when calling ./configure from MacOS X: The JCL extension to RxTx requires comm.jar If you intend to use RxTx for commapi support comm.jar needs to be located in /System/Library/Frameworks/JavaVM.framework/ Versions/1.5/Home/lib/ext/comm.jar I am wanting to build for the gnu.io package, since I want to jump ahead and see if the changes, intended for 2.18 for MacOS X, work for me. On a side note /Library/Java/Extensions should be included as a valid search path for the JAR, since this is where Apple recommends placing third party extensions (both Java and native). Andre From tjarvi at qbang.org Wed Jun 21 18:00:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:00:04 -0600 (MDT) Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I ask > this, because I see the following when calling ./configure from MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump ahead > and see if the changes, intended for 2.18 for MacOS X, work for me. > > On a side note /Library/Java/Extensions should be included as a valid > search path for the JAR, since this is where Apple recommends placing > third party extensions (both Java and native). > rxtx 2.1 src is obtained with "cvs checkout -r commapi-0-0-1 rxtx-devel" rxtx 2.0 src is obtained with "cvs checkout rxtx-devel" rxtx 2.1 is a complete package in namespace gnu.io rxtx 2.0 works with Sun's CommAPI v2.03 which is in namespace javax.comm. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:02:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:02:23 -0600 (MDT) Subject: [Rxtx] When is 2.18 planned for? In-Reply-To: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621141426.KDNA29052.tomts13-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Wed, 21 Jun 2006, Andre-John Mas wrote: > Hi, > > Just curious as to know if there is a target date for 2.18? > Hi Andre "When it is ready" :) Probably this weekend. Maybe sooner. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 18:10:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 18:10:18 -0600 (MDT) Subject: [Rxtx] RS 232 ..additional parameters In-Reply-To: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> References: <000601c6953a$b8b68910$2c02a8c0@elikasuhades> Message-ID: On Wed, 21 Jun 2006, Baris wrote: > Hi, > > Currently i am developing an application that requires to connect to a > remote rs232 device through a dialup connection. > > My problem is that the communication needs several more connection > parameters (i extracted that information from the vendor's dll , listed at > the end of the message) > > I explored rxtx API and src files and could not find methods to set a > majority of the parameters. > Am i missing any point or does rxtx is limited to soem standard set of > functionality(e.g. commAPI)? How is it possible ,if i want to put some > extensions(???) to current rxtx implementation? > > I am not very good at rs232 programming so excuse me if this message is > boring one. > > Thanx > Hi Baris > typedef struct _DCB { > typedef struct _COMMTIMEOUTS { These are all handled in termios.c. It is possible to add extensions to rxtx 2.1. It may well be that the defaults are the same for the variables not covered by the existing API. You can dump the DCB and COMMTIMEOUTS from inside termios.c to compare. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Jun 21 20:23:30 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 21 Jun 2006 20:23:30 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Message-ID: > I'm > not thrilled but OK with the current API. Hence I dont agree with > Paul's idea to start a new JSR to fix the implementation - but that's > mainly because I dont have the time to push it. According to their > Readme Sun sees no business case in having cross platform support for > javax.comm - that is sad but it's none of my business. However I > prefer to program versus javax.comm in my projects as this gives an > advanced user the chance to exchange the provider without access to > the code. Hi Joachim With regards to the JSR, I think that would be Doug's call. The effort I put in would have to be on my own time which would not be a great deal. I could help things go smoothly but thats not the same as pushing something through. -- Trent Jarvi tjarvi at qbang.org From vt at freehold.crocodile.org Wed Jun 21 21:05:22 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Wed, 21 Jun 2006 20:05:22 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? Message-ID: <449A08F2.3020106@freehold.crocodile.org> Hello all, I know this question may belong to JSR lists, but since all interested parties are here, I thought I just ask this question here, again... A while ago I run into a problem and wrote a rant, here: http://servomaster.sourceforge.net/dev/serial-usb.html At the time of writing I didn't think of adding another possible solution - changing the CommAPI specs to support removable devices. Apparently, Serial/USB bridges are here to stay, and this issue has to be addressed. Wonder if anything changed since, and any abstractions for supporting removable devices made it into current or future Java CommAPI drafts - Paul, any comments? --vt From joachim at buechse.de Thu Jun 22 01:59:54 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 09:59:54 +0200 Subject: [Rxtx] CVS build question In-Reply-To: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060621224129.PQJE13241.tomts10-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <73973465-7111-404E-BAEF-CF661A916628@buechse.de> Hello Andre, I am not sure how well the configure/make mechanism will work on OSX. I know that a while ago some contributors tried to get configure/make working on OSX but from comments I found in the readmes this work was only partially successfull. For compilation on OSX we have used the ProjectBuilder/XCode projects you can find in MACOSX_IDE. Regarding the ./configure comment: RXTX 2.0x needs the generic (ie 2.0.3/Solaris) comm.jar and a config file javax.comm.properties. The later MUST reside in {java.home}/lib. As the two only work together putting comm.jar into /Library/Java/ Extensions and hence making it available to all current and future VM installations will only add to confusion. Regards, Joachim On 22.06.2006, at 00:41, Andre-John Mas wrote: > Hi, > > Is the CVS repository meant to build for gnu.io or javax.comm? I > ask this, because I see the following when calling ./configure from > MacOS X: > > The JCL extension to RxTx requires comm.jar > If you intend to use RxTx for commapi support comm.jar > needs to be located in /System/Library/Frameworks/JavaVM.framework/ > Versions/1.5/Home/lib/ext/comm.jar > > I am wanting to build for the gnu.io package, since I want to jump > ahead and see if the changes, intended for 2.18 for MacOS X, work > for me. > > On a side note /Library/Java/Extensions should be included as a > valid search path for the JAR, since this is where Apple recommends > placing third party extensions (both Java and native). > > Andre > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jun 22 02:51:05 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 22 Jun 2006 10:51:05 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449A08F2.3020106@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> Message-ID: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Hello Vadim, I think that your rant is to the point. However it is a bit like saying that Windows is at the source of email degradation and the only solution is to have users switch to safer operating systems. I don't see how javax.comm or RXTX can address the problems you mention. Of course it would be super cool if javax.comm could magicly find the "matching" usb-device and query it's configuration via the usb protocol - however this magic (mapping /dev/xyz to its underlying USB device) is not supported by any kernel APIs I am aware of. It could be supported via POSSIX ioctl calls but then you should address your rant to the POSSIX group... So for the time beeing it's either up to the virtual comm port driver to provide a usefull name under /dev/ or to the user choosing the right port to use. One example of a smart(er) com port driver is the KDDI driver for OSX, which will create device names like "/dev/ cu.usbserial-0 CTRAQ2" where CTRAQ2 is an identifier string soft- encoded into the bridge chip. The same driver for windows also has some options allowing it in theory to recreate the same COMx every time a device is plugged/unplugged. For most industrial applications however it will be up to the user to choose the right port (without getting a lot of help doing so). Probing serial ports can go wrong, that's right. However any serial device developper would be well adviced to implement a basic set of Hayes AT modem commands (be it a modem or not). Especially AT I0. Anyone failing to do so risks that the users favourite TCP/PPP/FAX application or stack will kill the device in short time. Best regards, Joachim On 22.06.2006, at 05:05, Vadim Tkachenko wrote: > Hello all, > > I know this question may belong to JSR lists, but since all interested > parties are here, I thought I just ask this question here, again... > > A while ago I run into a problem and wrote a rant, here: > http://servomaster.sourceforge.net/dev/serial-usb.html > At the time of writing I didn't think of adding another possible > solution - changing the CommAPI specs to support removable devices. > Apparently, Serial/USB bridges are here to stay, and this issue has to > be addressed. > > Wonder if anything changed since, and any abstractions for supporting > removable devices made it into current or future Java CommAPI drafts - > Paul, any comments? > > --vt > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Thu Jun 22 13:16:03 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:16:03 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> Message-ID: <20060622191603.GA17487@freehold.crocodile.org> Hello Joachim, > I think that your rant is to the point. However it is a bit like > saying that Windows is at the source of email degradation and the > only solution is to have users switch to safer operating systems. I guess the problem is that the rant itself is obsolete and has to be updated according to latest developments. At the time of writing there weren't that many bridges around, and the trend didn't manifest itself as it does now. > I don't see how javax.comm or RXTX can address the problems you > mention. I would agree that javax.comm won't be able to address the problem, at least in the short run. As for RxTx - well, nobody prevents it from being a superset of CommAPI specification, right? RxTx being the de-facto standard for quite a few platforms, I'd daresay the standard may follow. > Of course it would be super cool if javax.comm could magicly find the > "matching" usb-device and query it's configuration via the usb protocol - > however this magic (mapping /dev/xyz to its underlying USB device) is not > supported by any kernel APIs I am aware of. It could be supported via > POSSIX ioctl calls but then you should address your rant to the POSSIX > group... As a matter of fact, my bigger concern is addressing the fact that a serial device can now be removable. This hasn't been the case before, and it clearly is now. Regarding the above, well, I guess if we accept this fact, we also need to accept the fact that we need at least rudimentary means of identification of a serial device. For the USB case, it would usually be the vendor/product ID, plus possible serial number - but it is irrelevant what exactly the identifying information is, as long as it allows to identify the device. A paradigm shift is required, this is what I wanted to say. Serial devices can be removed and replaced, it's now our turn to learn to deal with it. > Joachim --vt From jredman at ergotech.com Thu Jun 22 13:41:44 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 13:41:44 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622191603.GA17487@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> Message-ID: <449AF278.6000903@ergotech.com> Vadim Tkachenko wrote: > A paradigm shift is required, this is what I wanted to say. Serial devices > can be removed and replaced, it's now our turn to learn to deal with it. The removal if the serial port hardly significantly different from the removal of the device attached to the serial port. Different, slightly, but not a "paradigm shift". And yes, someone could unplug a USB serial device and plug it into a different USB port so that it has a different name/number, but they could do that with the device itself, move it from com1 to com2. Am I missing something? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 13:57:27 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 12:57:27 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449AF278.6000903@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> Message-ID: <20060622195727.GA20247@freehold.crocodile.org> On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > A paradigm shift is required, this is what I wanted to say. Serial devices > > can be removed and replaced, it's now our turn to learn to deal with it. > > The removal if the serial port hardly significantly different from the > removal of the device attached to the serial port. Different, > slightly, but not a "paradigm shift". > > And yes, someone could unplug a USB serial device and plug it into a > different USB port so that it has a different name/number, but they > could do that with the device itself, move it from com1 to com2. > > Am I missing something? Yes, the fact that they could unplug a device A and plug a device B. With the introduction of the concept of removability, the notion of the serial port itself is not as important anymore, but the notion of the unique device identifier is. Consider a situation: long running system (enterprise HVAC, tens of nodes, tens of thousands square feet area, hundreds of thousand dollars worth of equipment being conditioned, can't shut down), serial/usb device fails, is replaced by an identical device with a different serial #. A little bit farfetched, but hopefully highlighting the point I'm trying to make. > Jim --vt From jredman at ergotech.com Thu Jun 22 14:37:38 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 14:37:38 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <449AFF92.8080003@ergotech.com> Vadim Tkachenko wrote: >> >> Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. Serial devices are always removable. I could unplug _serial_ device A and plug in _serial_ device B. We have systems running with two RS485 ports, one talks to a Modbus PLC network one to a number of drives on a proprietary protocol. If you plug the wrong DB9 into the wrong port the application doesn't work. If you dangle a USB 485 converter on the end of the DB9 you've just moved the problem from RS485 to USB, but the problem/effect is the same. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. Nothing's changed. If I had a 4 port ISA board and plugged it into my new shiny '386 machine. I could have com ports 9-12. If I took a board off the shelf and didn't set the jumpers, I would have com ports 3-6. The problem's the same. If you replace with identical product then the com ports will be the same - no software changes required. If you replace one piece of hardware with hardware from a different manufacturer, then the naming/numbering may change. You're physically changing the system, so may reasonably expect to have to make a software change. RXTX actually handles this situation quite well with the -D command line option. (My experience has generally been that the port number depends more on the USB port used than the hardware - so the chances are even with a hardware change the port number/name will be the same.) Slightly Off Topic - there is a reason why industrial users will pay a premium for continued availability of hardware. Yes you can mail-order a $10 USB converter and it will work, but there's no guarantee that the next time you buy the same part number from the same vendor it will be the same. The industrial vendors will charge you $100+ for the same item, but it will be the same every time you buy it for the next 5 to 10 years. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 14:37:19 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 13:37:19 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622195727.GA20247@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> Message-ID: <20060622203719.GA22521@freehold.crocodile.org> Hello again, And while I'm at it, why don't just say this: give me one good reason to write 3+ different ways of handling removable devices, one for USB, one for FireWire, one for serial... I understand very well that this goes way beyond the scope of RxTx and CommAPI and will require cooperation between them and javax.usb and whatever JSR is responsible for FireWire implementation - but the end result is well worth it. Abstract out and generalize arrival/departure/monitoring/discovery API, provide protocol specific extensions for each, live happily ever after. --vt On Thu, Jun 22, 2006 at 12:57:27PM -0700, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 01:41:44PM -0600, Jim Redman wrote: > > > > Vadim Tkachenko wrote: > > > A paradigm shift is required, this is what I wanted to say. Serial devices > > > can be removed and replaced, it's now our turn to learn to deal with it. > > > > The removal if the serial port hardly significantly different from the > > removal of the device attached to the serial port. Different, > > slightly, but not a "paradigm shift". > > > > And yes, someone could unplug a USB serial device and plug it into a > > different USB port so that it has a different name/number, but they > > could do that with the device itself, move it from com1 to com2. > > > > Am I missing something? > > Yes, the fact that they could unplug a device A and plug a device B. With > the introduction of the concept of removability, the notion of the serial > port itself is not as important anymore, but the notion of the unique device > identifier is. > > Consider a situation: long running system (enterprise HVAC, tens of nodes, > tens of thousands square feet area, hundreds of thousand dollars worth of > equipment being conditioned, can't shut down), serial/usb device fails, is > replaced by an identical device with a different serial #. > > A little bit farfetched, but hopefully highlighting the point I'm trying to > make. > > > Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Thu Jun 22 15:13:49 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 Jun 2006 15:13:49 -0600 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622203719.GA22521@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> Message-ID: <449B080D.9080208@ergotech.com> Vadim Tkachenko wrote: > Hello again, > > And while I'm at it, why don't just say this: give me one good reason to > write 3+ different ways of handling removable devices, one for USB, one for > FireWire, one for serial... You don't, they're all the same "I have lost communication with my serial device". The only thing you could really do is improve error reporting by knowing the exact sub-system. ("Device X which is/was attached to USB port Y is no longer functioning, please check the USB ports, the device, the cables and anything else you can think of that may be a cause of failure.") That just requires an intelligent description of the port. > I understand very well that this goes way beyond the scope of RxTx and > CommAPI and will require cooperation between them and javax.usb and whatever > JSR is responsible for FireWire implementation - but the end result is well > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > API, provide protocol specific extensions for each, live happily ever after. There's a huge list of pseudo-serial devices each with a different set of requirements, Bluetooth, RFC 2217, a host of proprietary systems, etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I have no clue how you'd implement them in a general/cross platform sense. You haven't convinced me (and only me, others may see something that I don't, I'm not speaking for them) that this mechanism can be implemented in any practical sense. That is, that the implementation could be wide enough to be consider generally available in RXTX regardless of the serial port implementation, platform, etc.. However, if you can come up with a general design and a reference implementation for one subsystem, I'd like to see it and might get on board. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From vt at freehold.crocodile.org Thu Jun 22 15:40:55 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Thu, 22 Jun 2006 14:40:55 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <449B080D.9080208@ergotech.com> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> Message-ID: <20060622214055.GA25497@freehold.crocodile.org> On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: > > Vadim Tkachenko wrote: > > Hello again, > > > > And while I'm at it, why don't just say this: give me one good reason to > > write 3+ different ways of handling removable devices, one for USB, one for > > FireWire, one for serial... > > You don't, they're all the same "I have lost communication with my > serial device". "I have lost communication with my ${protocol} device". > The only thing you could really do is improve error reporting by knowing > the exact sub-system. ("Device X which is/was attached to USB port Y is > no longer functioning, please check the USB ports, the device, the > cables and anything else you can think of that may be a cause of > failure.") "Device ${id} which is/was attached to ${protocol} port ${port} is no longer functioning, please check the ${protocol} ports, the device, the ${protocol_media} and anything else you can think of that may be a cause of failure". > That just requires an intelligent description of the port. Agree absolutely. > > I understand very well that this goes way beyond the scope of RxTx and > > CommAPI and will require cooperation between them and javax.usb and whatever > > JSR is responsible for FireWire implementation - but the end result is well > > worth it. Abstract out and generalize arrival/departure/monitoring/discovery > > API, provide protocol specific extensions for each, live happily ever after. > > There's a huge list of pseudo-serial devices each with a different set > of requirements, Bluetooth, RFC 2217, a host of proprietary systems, > etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I > have no clue how you'd implement them in a general/cross platform sense. That's because some of the protocols were created decades ago when autoconfiguration wasn't even conceived, much less practical. RS232/RS485 don't have a clue about identity discovery, and even capabilities discovery beyond obvious 8N1 etc. I agree that today all these protocols have generally incompatible strategies for handling the situations I'm trying to address, but there's nothing that says it's not an oversight. Besides, we're dealing with the devices at a level of abstraction that allows some simplifications and generalizations, at least part of the time - unless it's the protocol specific features we're dealing with. > You haven't convinced me (and only me, others may see something that I > don't, I'm not speaking for them) that this mechanism can be implemented > in any practical sense. That is, that the implementation could be wide > enough to be consider generally available in RXTX regardless of the > serial port implementation, platform, etc.. However, if you can come up > with a general design and a reference implementation for one subsystem, > I'd like to see it and might get on board. Actually, I wasn't even thinking about all this stuff when I wrote the first message on the subject :) Now that you mention it - well, I'm not sure I can chew the piece I just tried to bite in reasonable amount of time. How do you eat an elephant? One bite at a time. If we could agree that a small step in the specification is acceptable at this time, and express further intentions, things may start happening. To put it succinctly: - Concept of a "port" should be augmented with a concept of a "device". A device may be attached to a port in an implicit or explicit way. - Implicitly connected device is exactly what the current scope of the specification covers. No new functionality is offered. - Explicitly connected device supports detachable device semantics, just as other protocols do (USB, FireWire, Wireless USB, Bluetooth, to mention a few). - The input and output streams are not properties of a port now, but properties of the device attached to the port. - A mechanism to allow listening for device arrivals and departures must be made available. That's it, off the top of my head. I understand that this goes completely against current javax.comm specs, but an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) won't be difficult to implement without disrupting javax.comm compatibility. One concern is how to deal with the device identity - but there's no general way of dealing with this at this time, devices may or may not offer identity discovery. > Jim --vt From joachim at buechse.de Fri Jun 23 02:12:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 23 Jun 2006 10:12:43 +0200 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: <20060622214055.GA25497@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: Hello++ Vadim, I would like to repeat that your request is best addressed to the POSSIX standardization group - or maybe the BSD/Linux maintainers. If you convince the BSD or Linux guys to add this kind of functionality (they can as most of there VCP drivers are open source), there is a certain chance that other vendors will pick it up. I assure you that RXTX will happily provide this functionality once it's possible - I'm sure there is more than one maintainer that would love to add it. Having this concept penetrate the market may take some years though. SHORT: The solution you would like to see could be added to the API but it can not be implemented (at least not on the platforms I know). There are currently no hooks in the kernel that allow you to discover "the device" or even the "means of connection" based on an existing "device file descriptor" ie COM-port or /dev/... entry. The name mapping of the device is handled by the virtual com port driver of the device. Unless you are suggesting RXTX should reimplement virtual com port drivers for all usb/serial bridges out there your request is understandable from a users viewpoint but simply not realizable. It's like asking that the Socket api should identify the computer behind an IP address (ie by its Ethernet address). While this COULD be implemented in TCP/IP, it IS not, and hence there is no point adding such a function to the Socket API. The current trend for USB/Bluetooth/Irda/etc connected devices is going away from serial port abstraction towards RPC (ie the drivers provide a device specific or device class specific driver that provides an application level api to the device functions). The line level protocol is often not even published. Best regards, Joachim On 22.06.2006, at 23:40, Vadim Tkachenko wrote: > On Thu, Jun 22, 2006 at 03:13:49PM -0600, Jim Redman wrote: >> >> Vadim Tkachenko wrote: >>> Hello again, >>> >>> And while I'm at it, why don't just say this: give me one good >>> reason to >>> write 3+ different ways of handling removable devices, one for >>> USB, one for >>> FireWire, one for serial... >> >> You don't, they're all the same "I have lost communication with my >> serial device". > > "I have lost communication with my ${protocol} device". > >> The only thing you could really do is improve error reporting by >> knowing >> the exact sub-system. ("Device X which is/was attached to USB >> port Y is >> no longer functioning, please check the USB ports, the device, the >> cables and anything else you can think of that may be a cause of >> failure.") > > "Device ${id} which is/was attached to ${protocol} port ${port} is > no longer > functioning, please check the ${protocol} ports, the device, the > ${protocol_media} and anything else you can think of that may be a > cause of > failure". > >> That just requires an intelligent description of the port. > > Agree absolutely. > >>> I understand very well that this goes way beyond the scope of >>> RxTx and >>> CommAPI and will require cooperation between them and javax.usb >>> and whatever >>> JSR is responsible for FireWire implementation - but the end >>> result is well >>> worth it. Abstract out and generalize arrival/departure/ >>> monitoring/discovery >>> API, provide protocol specific extensions for each, live happily >>> ever after. >> >> There's a huge list of pseudo-serial devices each with a different >> set >> of requirements, Bluetooth, RFC 2217, a host of proprietary systems, >> etc. etc.. Discovery under Bluetooth, or 802.11 would be cool, but I >> have no clue how you'd implement them in a general/cross platform >> sense. > > That's because some of the protocols were created decades ago when > autoconfiguration wasn't even conceived, much less practical. RS232/ > RS485 > don't have a clue about identity discovery, and even capabilities > discovery > beyond obvious 8N1 etc. > > I agree that today all these protocols have generally incompatible > strategies for handling the situations I'm trying to address, but > there's > nothing that says it's not an oversight. Besides, we're dealing > with the > devices at a level of abstraction that allows some simplifications and > generalizations, at least part of the time - unless it's the protocol > specific features we're dealing with. > >> You haven't convinced me (and only me, others may see something >> that I >> don't, I'm not speaking for them) that this mechanism can be >> implemented >> in any practical sense. That is, that the implementation could be >> wide >> enough to be consider generally available in RXTX regardless of the >> serial port implementation, platform, etc.. However, if you can >> come up >> with a general design and a reference implementation for one >> subsystem, >> I'd like to see it and might get on board. > > Actually, I wasn't even thinking about all this stuff when I wrote > the first > message on the subject :) Now that you mention it - well, I'm not > sure I can > chew the piece I just tried to bite in reasonable amount of time. > > How do you eat an elephant? One bite at a time. If we could agree > that a > small step in the specification is acceptable at this time, and > express > further intentions, things may start happening. > > To put it succinctly: > > - Concept of a "port" should be augmented with a concept of a > "device". A > device may be attached to a port in an implicit or explicit way. > - Implicitly connected device is exactly what the current scope of the > specification covers. No new functionality is offered. > - Explicitly connected device supports detachable device semantics, > just as > other protocols do (USB, FireWire, Wireless USB, Bluetooth, to > mention a > few). > - The input and output streams are not properties of a port now, but > properties of the device attached to the port. > - A mechanism to allow listening for device arrivals and departures > must be > made available. > > That's it, off the top of my head. > > I understand that this goes completely against current javax.comm > specs, but > an adapter (as in http://en.wikipedia.org/wiki/Adapter_pattern ) > won't be > difficult to implement without disrupting javax.comm compatibility. > > One concern is how to deal with the device identity - but there's > no general > way of dealing with this at this time, devices may or may not offer > identity > discovery. > >> Jim > > --vt > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From vt at freehold.crocodile.org Fri Jun 23 11:28:29 2006 From: vt at freehold.crocodile.org (Vadim Tkachenko) Date: Fri, 23 Jun 2006 10:28:29 -0700 Subject: [Rxtx] Removable device arrival/departure semantics for CommAPI? In-Reply-To: References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> Message-ID: <20060623172829.GA5335@freehold.crocodile.org> Hello Joachim, > I would like to repeat that your request is best addressed to the POSSIX > standardization group - or maybe the BSD/Linux maintainers. If you > convince the BSD or Linux guys to add this kind of functionality (they can > as most of there VCP drivers are open source), there is a certain chance > that other vendors will pick it up. I assure you that RXTX will happily > provide this functionality once it's possible - I'm sure there is more > than one maintainer that would love to add it. I realize this thing is bigger than RxTx itself, and I'm afraid it's too global not to cause people to laugh before they think about it :) > Having this concept penetrate the market may take some years though. Well, I'm sure it'll get there, the only question is - when. > SHORT: The solution you would like to see could be added to the API but it > can not be implemented (at least not on the platforms I know). I guess I'm concerned about the abstraction more than I'm concerned about the implementation at this point. > There are currently no hooks in the kernel that allow you to discover > "the device" or even the "means of connection" based on an existing > "device file descriptor" ie COM-port or /dev/... entry. Well, I'm not so sure you need to keep the literal mapping from /dev namespace to your device namespace. As long as you can consistently offer a virtual serial device on top of a virtual serial port, it may be irrelevant whether you can map it into /dev. The mapping is going be schitzofrenic anyway - /dev/ttyS*, /proc/bus/usb/* or whatever else is the representation... > The name mapping of the device is handled by the virtual com port driver > of the device. Unless you are suggesting RXTX should reimplement virtual > com port drivers for all usb/serial bridges out there your request is > understandable from a users viewpoint but simply not realizable. It's not so much a request but rather an offer of participation. I run a few projects actively using serial communications, as well as USB device drivers, in different degrees of readiness (Servomaster, Haywire, DIY Zoning) - and it would be a perfect playground. You mentioned above that this task is about two things: a) abstraction b) implementation. I could start the abstraction part of it without changing the current CommAPI, on top of it, as an adapter. Even if the removable device semantics are not implemented, but offered, this is already a step forward. > It's like asking that the Socket api should identify the computer behind > an IP address (ie by its Ethernet address). While this COULD be > implemented in TCP/IP, it IS not, and hence there is no point adding such > a function to the Socket API. Thank you for bringing up this example - I guess this is just about the same thing that I'd like to see. Socket transparently provides you with the input/output streams, at the same time offering protocol level specifics to you. > The current trend for USB/Bluetooth/Irda/etc connected devices is going > away from serial port abstraction towards RPC (ie the drivers provide a > device specific or device class specific driver that provides an > application level api to the device functions). The line level protocol is > often not even published. I can't say I'm that happy with it. The best (or, rather, worst) example is suchlike support for the Phidget servo controller - zealous Linux developers implemented kernel module support for it, completely hijacking a possibility of using it on a different level (it's somewhat fixed by now, thankfully). I believe that whenever an abstraction is offered, it must be made optional and/or pluggable so it can be replaced by something more suited to the task. The nature of Java applications is such that they'd probably care much more about Java API offered, than about no matter how rich application level api that is offered outside of Java. I've dealt with JNI adapters in the past, and whereas they can be made reasonably stable, the very fact that you are forced to deal with things that are not on the critical timing/memory path and could've been done much easier in Java causes endless grief. > Joachim --vt From lyon at docjava.com Sat Jun 24 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 24 Jun 2006 06:54:12 -0400 Subject: [Rxtx] jsr In-Reply-To: <20060623172829.GA5335@freehold.crocodile.org> References: <449A08F2.3020106@freehold.crocodile.org> <2853E01B-F93A-4B5A-B78B-00BBD98E011E@buechse.de> <20060622191603.GA17487@freehold.crocodile.org> <449AF278.6000903@ergotech.com> <20060622195727.GA20247@freehold.crocodile.org> <20060622203719.GA22521@freehold.crocodile.org> <449B080D.9080208@ergotech.com> <20060622214055.GA25497@freehold.crocodile.org> <20060623172829.GA5335@freehold.crocodile.org> Message-ID: Hi All, I have had some off-list discussion with Trent. Opening up a JSR with Sun, as per Peters' suggestion seems like a reasonable idea, to us. Does anyone having any concerns about the JSR process that they would like to raise? Thanks! - Doug From the.grey.lantern at gmail.com Sat Jun 24 18:15:26 2006 From: the.grey.lantern at gmail.com (Craig Nicoll) Date: Sun, 25 Jun 2006 01:15:26 +0100 Subject: [Rxtx] Cannot create virtual serial port Message-ID: Hello, This is my first post on this mailing list and I hope someone can help me. I am having great difficult establishing a virtual serial port for the Bluetooth connection between my Laptop (running OpenSUSE 10.1) and my Nokia 7600. Every time I try to run the SendMessage program that comes with SMSLib, I get the following exception: gnu.io.NoSuchPortException The port names I have tried are: rfcomm0 rfcomm /dev/rfcomm0 /dev/rfcomm This is what I have done so far: Modified /etc/bluetooth/rfcomm.conf to include the address of my phone: rfcomm0 { # Automatically bind the device at startup bind no; # Bluetooth address of the device device 00:0e:6d:7a:98:43; # RFCOMM channel for the connection channel 1; # Description of the connection comment "Example Bluetooth device"; } I also tried running the following command: rfcomm bind /dev/rfcomm0 I have searched the mailing list archives and found this post where someone had a very similar problem to me: http://marc.theaimsgroup.com/?t=108443982800001&r=1&w=2 However, I tried changing the system properties as suggested and it made no difference. I have also been scouring Google all day to no avail. I would be incredibly grateful if anyone could give me some tips. Thank you, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060624/cfa6df35/attachment-0065.html From tjarvi at qbang.org Sun Jun 25 19:56:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 25 Jun 2006 19:56:08 -0600 (MDT) Subject: [Rxtx] Pending release Message-ID: With frustration, I was unable to get to the pending release this weekend. The release should be comming this next week once things calm down. The source is in CVS except for a fix for multiple ports in windows. I had planned on doing the release this weekend but that was disrupted by my transportation failing in a spectacular fashion. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Mon Jun 19 05:54:49 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 13:54:49 +0200 Subject: [Rxtx] gnu.io.PortInUseException: Unknown Application ??? In-Reply-To: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> References: <8B657BED-4CF2-4C3B-9729-16B0E610109D@sympatico.ca> Message-ID: <3D29EC8F-AC14-49ED-9AA1-6A555E944254@buechse.de> This is most likely due to a problem with lock files. If you have downloaded the binaries of 2.17 rxtx will try to create non-standard lock files on OSX. We have since changed the code to use OSX device locking - however the binaries have not been updated yet. The 2.18 release fixing this issue is due shortly. Regards, Joachim On 19.06.2006, at 01:33, Andr?-John Mas wrote: > Hi, > > I am have a program that I wrote in Java to communicate with a > Bluetooth GPS device. I am > trying to get this working on my Mac, but I keep getting told that: > > gnu.io.PortInUseException: Unknown Application > > but > > portIdentifier.isCurrentlyOwned() > > returns false and when I do lsof on the device I am trying to connect > to, I see no application > using it. As the same time if I go to the command line and use > minicom I have no issues. The > exception happens with this call: > > CommPort commPort = portIdentifier.open(null,0); > > Any suggestions? > > Andre > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jun 19 06:44:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 14:44:27 +0200 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <4490A60A.9090305@sun.com> References: <4490A60A.9090305@sun.com> Message-ID: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Hello Paul, I just downloaded the "generic" javax.comm version now available. A first check indicates, that it was compiled with a JDK 1.4 javac without setting the target classfile version. In other words in can not be loaded by 1.1-1.3 VMs (or PersonalJava). Do you see any chance to provide a version compiled with classfile format 45.3 (ie JVM1.1). --- 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose javax.comm.SerialPort | head -5 Compiled from "SerialPort.java" public abstract class javax.comm.SerialPort extends javax.comm.CommPort SourceFile: "SerialPort.java" minor version: 0 major version: 48 --- Best regards, Joachim On 15.06.2006, at 02:12, Paul Klissner wrote: > Hello RxTx community, > > I finally think I have a compromise in place that will stand in the > gap. > > If you go to http://www.sun.com and search for javax.comm, you'll > get taken to a download page, where now users can get a copy of the > comm.jar file out of 2.0.3, along with just a license and a README. > > I trust this will suffice until such time as RxTx decided to implement > their own java classes or we can get a JSR going to mitigate some > of the problems (the readme in the comm.jar 2.0.3 zip file > contains my thoughts on that). > > Thanks, > Paul > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jun 19 09:11:45 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 19 Jun 2006 11:11:45 -0400 Subject: [Rxtx] Examples added to Wiki Message-ID: <20060619151145.TFB1543.tomts43-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have added a couple of examples to the Wiki: http://rxtx.qbang.org/wiki/index.php/Examples If anyone has others they want to contribute, or want to update what is there feel free. We all benefit :) Andre From paul.klissner at sun.com Mon Jun 19 10:42:47 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Mon, 19 Jun 2006 09:42:47 -0700 Subject: [Rxtx] javax.comm comm.jar 2.0.3 now available from Sun In-Reply-To: <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> References: <4490A60A.9090305@sun.com> <03F7A99F-F0FF-4BC4-892A-2393596DB432@buechse.de> Message-ID: <4496D407.1090609@sun.com> Joachim Buechse wrote: > Hello Paul, > > I just downloaded the "generic" javax.comm version now available. A > first check indicates, that it was compiled with a JDK 1.4 javac > without setting the target classfile version. In other words in can > not be loaded by 1.1-1.3 VMs (or PersonalJava). > > Do you see any chance to provide a version compiled with classfile > format 45.3 (ie JVM1.1). > > --- > 52:~/Desktop/comm2.0.3 joachim$ javap -classpath comm.jar -verbose > javax.comm.SerialPort | head -5 > Compiled from "SerialPort.java" > public abstract class javax.comm.SerialPort extends javax.comm.CommPort > SourceFile: "SerialPort.java" > minor version: 0 > major version: 48 > --- I cannot promise when I can do that. Since we thought we were done with javax.comm, the build environment got moved around, and right now it doesn't even compile in it's new home. I tried and it was not cooperative at all. I was never impressed with that workspace (in fact far far from it, it is a mess, which is why I migrated 3.0 to ant and never looked back). It will take some real determination for me to rebuild it, and frankly, right now I'm swamped. If I can find a bit of time over the next few weeks to do it, and it isn't too bad an ordeal, I will. Posting that will give me an excuse to post javax.comm 3.0, Update 2 as well, while I'm working with the people who put content up on our download center. The only reason for a new update to 3.0 is that I've changed the distribution to provide ispt (Interactive Serial Port Tool), such that it can be launched as soon as the zip file is unpacked, via a provided script. ISPT is a command line interactive tool for manipulating one or two serial port, sending data, managing events, etc... I've found it to be so useful for doing certain kinds of validation that I assume others will find it useful to. ISPT is already in 3.0u1, but one has to set up their own classpath and launch it and since few people ever read the documentation most won't know about it. I've added the ability to set stop bits and parity since 3.0u1 too. But I digress. Paul From joachim at buechse.de Mon Jun 19 11:01:28 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 19 Jun 2006 19:01:28 +0200 Subject: [Rxtx] load mechanism of 2.0x Message-ID: Good day, I am trying to figure out, how the 2.0x distribution interacts with Suns implementation of javax.comm.CommPortIdentifier. 1) Apparently one can put javax.comm.properties in {java.home}/lib 2) The javax.comm package also reacts to -Djavax.comm.properties="...." Looking at the javap output it also seems like CommPortIdentifier tries to find it's jar file and load the properties from there?? What I'm really looking for is a solution that allows using javax.comm with RXTX without modifying the VM installation. So I would prefer not to use 1) but I can't figure out how to use 2). Any hints are welcome, Joachim From bob_tai2001 at yahoo.com Mon Jun 19 15:00:35 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 19 Jun 2006 14:00:35 -0700 (PDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? Message-ID: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Hi, I got rxtx Windows 2000 installed. I did not use the "best" way ... I just follow the insturuction and dump the necessary files into the jre... I know it's "best" idea, I got lazy didn't want to change my setting to my Eclipse and classpath. I was able to modify SimpleWrite.java to print on my AddMaster serial printer. I think I am ready to code! But I need to make sure I can handle exceptions and so on. I notice the \samples\NullDriver\ has two files seems to have some of the require method done, should I start coding from those file? I like the idea it has the "time out" and basic exceptions done. I am slowly digging into the samples, but if you think any of the code from Sun is good to checkout please let me know. btw, http://rxtx.qbang.org/wiki/index.php/Examples/ was very helpful, wish there are more examples. thank you, Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tjarvi at qbang.org Mon Jun 19 15:55:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 19 Jun 2006 15:55:40 -0600 (MDT) Subject: [Rxtx] newbie: is \samples\NullDriver\NullDriver.java a good place to start? In-Reply-To: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> References: <20060619210035.75260.qmail@web32806.mail.mud.yahoo.com> Message-ID: > I am > slowly digging into the samples, but if you think any > of the code from Sun is good to checkout please let me > know. > I think NullDriver.java was an example stub driver for implementing something like rxtx. It has been a while. Unless they have been updated, you will find the examples are very dated. You can look at how they use the port but avoid the GUI and hard coded variables (number of ports for instance). There was no Swing and nobody knew what requirements today's compilers would make on code. The examples worked fine with jdk 1.1 but times have changed. -- Trent Jarvi tjarvi at qbang.org From tropicsu at hotmail.com Mon Jun 19 19:49:08 2006 From: tropicsu at hotmail.com (Yoke K) Date: Tue, 20 Jun 2006 01:49:08 +0000 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060619/fa588f00/attachment-0071.html From ajmas at sympatico.ca Mon Jun 19 21:14:37 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Mon, 19 Jun 2006 23:14:37 -0400 Subject: [Rxtx] RXTX-2.1-7 / MAC OS X / NoSuchPortException In-Reply-To: References: Message-ID: Regarding the PortInUseException, I had a similar issue and got this response from the mailing list: http://mailman.qbang.org/pipermail/rxtx/Week-of- Mon-20060619/062838.html Andre On 19-Jun-06, at 21:49 , Yoke K wrote: > Hi Andre, Joachim > > I have tried using /dev/tty.usbserial and also /dev/cu.usbserial > and it also reported error as "gnu.io.PortInUseException". > > The iTegno modem works in windows environment. As I moving around > using my ibook and I need to get it work on MAC OS as well. > > >> INFO: SMSLib API for Java / v1.2.2 > >> INFO: Using port: /dev/tty.usbserial @ 115200 baud. > >> INFO: JRE Version: 1.5.0_06 > >> INFO: JRE Impl Version: 1.5.0_06-64 > >> INFO: O/S: Mac OS X / ppc / 10.4.6 > >> INFO: Using Wavecom (Generic) AT handler. > > SendMessage(): Send a message. > Using SMSLib API for Java v1.2.2 > > Connecting ..... : > >> INFO: CSerialDriver(): Connecting... > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >> INFO: CSerialDriver(): Disconnecting... > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier. java:354) > at org.smslib.CSerialDriver.open(CSerialDriver.java:7 1) > at org.smslib.CService.connect(CService.java:197) > at SendMessage.main(SendMessage.java:38) > > Thanks. > > - Jon > > > > > ==================== > > Hello Jon, > > From OSX's standpoint a symbolic link is not a device (as far as I > know). What stops you from using tty.usbserial? Did you try hard- > linking? > > Regards, > Joachim > > > > From: "Yoke K" > To: rxtx at qbang.org > Subject: RXTX-2.1-7 / MAC OS X / NoSuchPortException > Date: Sat, 17 Jun 2006 15:32:48 +0000 > >Hi, > > > >I am having problem getting SMSLIB version 1.2.2 and RXTX-2.1-7 to > >work with MAC OS X. > >I am using iTegno 3000 - USB GPRS Modem. > > > >Files in /dev and a symbolic link as follows: > > > >crw-rw-rw- 1 root wheel 9, 9 Jun 17 22:58 cu.usbserial > >crw-rw-rw- 1 root wheel 9, 8 Jun 17 22:58 tty.usbserial > >lrwxr-xr-x 1 root wheel 0 Jun 17 22:37 ttyS1 -> > >tty.usbserial > > > >In my SendMessage.java, I have this line: > >CService srv = new CService("/dev/ttyS1", 56000, "Wavecom", ""); > > > >Appreciate any help ? > > > >- Jon > > > > > >Errors as follows: > > > >>>INFO: SMSLib API for Java / v1.2.2 > >>>INFO: Using port: /dev/ttyS1 @ 56000 baud. > >>>INFO: JRE Version: 1.5.0_06 > >>>INFO: JRE Impl Version: 1.5.0_06-64 > >>>INFO: O/S: Mac OS X / ppc / 10.4.6 > >>>INFO: Using Wavecom (Generic) AT handler. > > > >SendMessage(): Send a message. > > Using SMSLib API for Java v1.2.2 > > > >Connecting ..... : > >>>INFO: CSerialDriver(): Connecting... > >Experimental: JNI_OnLoad called. > >Stable Library > >========================================= > >Native lib Version = RXTX-2.1-7 > >Java lib Version = RXTX-2.1-7 > >>>INFO: CSerialDriver(): Disconnecting... > >gnu.io.NoSuchPortException > > at > >gnu.io.CommPortIdentifier.getPortIdentifier > (CommPortIdentifier.java:218) > > at org.smslib.CSerialDriver.open(CSerialDriver.java:70) > > at org.smslib.CService.connect(CService.java:197) > > at SendMessage.main(SendMessage.java:38) > > > >_________________________________________________________________ > >Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/ > > > > Find love online with MSN Personals > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Tue Jun 20 02:35:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:35:24 +0200 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x Message-ID: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Hello everybody, I have been fighting a bit with the javax.comm version of RXTX the last days. I am working on the README .OSX now and try to figure out which should be the "suggested" installation. The facts: ------ - the "generic" comm.jar version of javax.comm which has been made re- available tries to load com.sun.comm.SolarisDriver - this classname can be overridden ONLY by putting a file javax.comm.properties in {java.home}/lib - if it is not overridden and SolarisDriver.class is not found CommPortIdentifier will be disfunctional (in particual it is not possible to add CommPort's via CommPortIdentifier.add). - the license distributed with comm.jar does not allow the modification/addition of classes in javax.comm (however no mention of com.sun...) What really bothers me is to suggest putting this config file in the "global" vm installation. This is particularly ugly on the Mac as there are several VM installations and the file may be forgotten. Additionally it may create versioning problems. I prefer an installation where all files are local to the application (even comm.jar). In my opinion the ideal situation would be: ------ 1) The author of a program compiles against javax.comm. 2a) For platforms supported by Sun the user is free to use the 3.0 comm.jar download from Sun 2b) For platforms not supported by Sun the user adds RXTXComm.jar to the classpath of the application (and librxtxSerial.jnilib to the application directory). Also he will need the 2.0.3 generic comm.jar from Sun. 3) Nobody messes with the global VM installation. Of course 2a) and 2b) could be handled by the author of the program via an appropriate installer. The author could also decide to always use RXTX and include the generic javax.comm classes as well as the RXTX classes in his application jar. [If he further uses an explicit call to System.load() he may even include the jnilib(s) in the jar, extract it (based on the platform name) at runtime to a temp file and load it from there.] Suggested solution: ------ We only need to put the following class in the classpath BEFORE Suns comm.jar package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } This is not "the pure art" (TM). It depends on an implementation detail of the generic driver. However, so does the javax.comm.properties file - as we have seen when Sun released 3.0. It has the following advantages: - The "generic" javax.comm implementation will happily load this class as its primary driver. - No javax.comm.properties file is required. - This does not violate the javax.comm license agreement as there is no mention of the "com.sun.comm" package in this license agreement at all. - Authors packaging comm.jar with their application can strip out all com.sun.comm classes from comm.jar Please comment! Joachim From joachim at buechse.de Tue Jun 20 02:50:36 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 10:50:36 +0200 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar Message-ID: There has been some discussions about the best way to install RXTX and where to place files. I suggest that, - we include the native libraries for the most common operating systems (in a special version of) RXTXcomm.jar - we add loader code which tries to extract and load the platform specific binary at runtime - on failure the current mechanism remains as a fallback Wether the current mechanism should have priority (ie loadLibrary before load) remains to be discussed. The advantages of this solution are - users of RXTX do not need to worry about java/platform specific file placement. - authors of applications may fully merge RXTX into their application jar (which provides a double-clickable application for Windows and OSX, Linux?). Please comment, Joachim PS: Of course the suggested solution is already possible today, however relatively few programmers know how to correctly extract a binary resource file via the class loader and load it as a native library. From tjarvi at qbang.org Tue Jun 20 03:58:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 03:58:12 -0600 (MDT) Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. As there are no plans to support CommAPI 3.0 due to the limitations in its implementation mentioned before, I would not recommend projects use Sun's 3.0 comm.jar. They will lose the freedom to chose their low level implementation by being locked into vendor specific modifications. Projects should chose between platform neutrality in CommAPI 2.0 and reduced platform neutrality in commapi 3.0. Projects should also strongly consider the fact that the 2.0 comm.jar targets only a reduced number of JVMs. Projects can go with rxtx 2.1 or other packages but should probably only consider using Sun CommAPI with rxtx if they did so in the past. They should take steps to no longer depend upon this option being available. > Suggested solution: > ------ > > We only need to put the following class in the classpath BEFORE Suns > comm.jar > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > This is not "the pure art" (TM). It depends on an implementation > detail of the generic driver. However, so does the > javax.comm.properties file - as we have seen when Sun released 3.0. > It has the following advantages: > > - The "generic" javax.comm implementation will happily load this > class as its primary driver. > - No javax.comm.properties file is required. > - This does not violate the javax.comm license agreement as there is > no mention of the "com.sun.comm" package in this license agreement at > all. > - Authors packaging comm.jar with their application can strip out all > com.sun.comm classes from comm.jar > I would not encourage people to place packages in the com.sun.comm namespace. Authors using Sun's commapi 2.0 should just realize it is greatly limited in practical utility and consider moving to something that isn't being rescued from EOL. The primary focus of this release is projects previously depending upon Sun CommAPI + RXTX. There are no plans at this time to provide future support in this arrangement due to technical incompatabilities we have no control over in commapi 3.0 and limited utility of Sun's generic comm.jar in commapi 2.0 offered. Projects should be aware of this so they can make appropriate plans. -- Trent Jarvi tjarvi at qbang.org From paul.klissner at sun.com Tue Jun 20 05:24:00 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:24:00 -0700 Subject: [Rxtx] Request for comment: Suggested installation RXTX 2.0x In-Reply-To: References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DAD0.10803@sun.com> Trent Jarvi wrote: >> 2a) For platforms supported by Sun the user is free to use the 3.0 >> comm.jar download from Sun >> 2b) For platforms not supported by Sun the user adds RXTXComm.jar to >> the classpath of the application (and librxtxSerial.jnilib to the >> application directory). Also he will need the 2.0.3 generic comm.jar >> from Sun. > > As there are no plans to support CommAPI 3.0 due to the limitations in its > implementation mentioned before, I would not recommend projects use Sun's > 3.0 comm.jar. They will lose the freedom to chose their low level > implementation by being locked into vendor specific modifications. > > Projects should chose between platform neutrality in CommAPI 2.0 and > reduced platform neutrality in commapi 3.0. Projects should also strongly > consider the fact that the 2.0 comm.jar targets only a reduced number of > JVMs. Well, that's a little ambiguous because the API is the same either way. We're talking about Sun's implementation vs. other implementations. > > Projects can go with rxtx 2.1 or other packages but should probably only > consider using Sun CommAPI with rxtx if they did so in the past. They > should take steps to no longer depend upon this option being available. 3.0 is platform centric because there is a need to add some platform awareness to Sun's implementation, and the choices for how to do that are limited by the constraints of the API, as mentioned in the javax.comm 2.0.3 comm.jar download's README. I am really advocating getting a JSR open (http://www.jcp.org) to push a new comm API that is more pluggable, platform neutral and addresses some of the deficiencies of the current API. Then we can achieve the optimal of platform neutrality while simulataneously allowing the API to flexibly adapt to heterogeneous environments. This is not a question of attitude, this is an issue of resources, time and commitment. The current owners of javax.comm within Sun would like nothing better than to see the ideal reached for the API and a model that will extend well beyond the foreseeable future and work for the industry overall. > >> Suggested solution: >> ------ >> >> We only need to put the following class in the classpath BEFORE Suns >> comm.jar >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> This is not "the pure art" (TM). It depends on an implementation >> detail of the generic driver. However, so does the >> javax.comm.properties file - as we have seen when Sun released 3.0. >> It has the following advantages: >> >> - The "generic" javax.comm implementation will happily load this >> class as its primary driver. >> - No javax.comm.properties file is required. >> - This does not violate the javax.comm license agreement as there is >> no mention of the "com.sun.comm" package in this license agreement at >> all. >> - Authors packaging comm.jar with their application can strip out all >> com.sun.comm classes from comm.jar >> > > I would not encourage people to place packages in the com.sun.comm > namespace. Authors using Sun's commapi 2.0 should just realize it is > greatly limited in practical utility and consider moving to something that > isn't being rescued from EOL. > > The primary focus of this release is projects previously depending upon > Sun CommAPI + RXTX. There are no plans at this time to provide future > support in this arrangement due to technical incompatabilities we have no > control over in commapi 3.0 and limited utility of Sun's generic comm.jar > in commapi 2.0 offered. Projects should be aware of this so they can make > appropriate plans. Unless you have Sun Ray thin clients on Linux or Solaris SPARC or Solaris x86, or need the powerful portmapping features in javax.com 3.0, or would like to acquire the Interactive Serial Port Test utility. -Paul From paul.klissner at sun.com Tue Jun 20 05:33:44 2006 From: paul.klissner at sun.com (Paul Klissner) Date: Tue, 20 Jun 2006 04:33:44 -0700 Subject: [Rxtx] Suggested installation RXTX 2.0x... In-Reply-To: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> References: <8BDF30B1-5C7D-47EC-B818-2E2917F1B84E@buechse.de> Message-ID: <4497DD18.70207@sun.com> Joachim Buechse wrote: > Hello everybody, > > I have been fighting a bit with the javax.comm version of RXTX the > last days. I am working on the README .OSX now and try to figure out > which should be the "suggested" installation. > > The facts: > ------ > > - the "generic" comm.jar version of javax.comm which has been made re- > available tries to load com.sun.comm.SolarisDriver > - this classname can be overridden ONLY by putting a file > javax.comm.properties in {java.home}/lib > - if it is not overridden and SolarisDriver.class is not found > CommPortIdentifier will be disfunctional (in particual it is not > possible to add CommPort's via CommPortIdentifier.add). > - the license distributed with comm.jar does not allow the > modification/addition of classes in javax.comm (however no mention of > com.sun...) > > > What really bothers me is to suggest putting this config file in the > "global" vm installation. This is particularly ugly on the Mac as > there are several VM installations and the file may be forgotten. > Additionally it may create versioning problems. I prefer an > installation where all files are local to the application (even > comm.jar). > > In my opinion the ideal situation would be: > ------ > > 1) The author of a program compiles against javax.comm. > 2a) For platforms supported by Sun the user is free to use the 3.0 > comm.jar download from Sun > 2b) For platforms not supported by Sun the user adds RXTXComm.jar to > the classpath of the application (and librxtxSerial.jnilib to the > application directory). Also he will need the 2.0.3 generic comm.jar > from Sun. > 3) Nobody messes with the global VM installation. > > Of course 2a) and 2b) could be handled by the author of the program > via an appropriate installer. The author could also decide to always > use RXTX and include the generic javax.comm classes as well as the > RXTX classes in his application jar. [If he further uses an explicit > call to System.load() he may even include the jnilib(s) in the jar, > extract it (based on the platform name) at runtime to a temp file and > load it from there.] > This was how the Sun implementation originated (I did not write that code). I completely agree, and I fixed the whole conf file locating mechanism in 3.0 to avoid the problems youmentioned. However, I was unaware of how RxTx was using Sun's implementation, so I didn't architect it in such a way as to avoid namespace pollution in the native space in for the backend provider. In retrospect, I should have done that differently just as a design principle, but at this point I don't have the spare cycles to get that all re-factored. Further, I'm loathe to do it, because the whole thing will still be an under-the-hood hack due to the constraints of the API itself. Paul From brian at mbari.org Tue Jun 20 10:23:54 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 20 Jun 2006 09:23:54 -0700 Subject: [Rxtx] Request for comment: Inclusion of native libs in RXTXcomm.jar In-Reply-To: References: Message-ID: <6B5D64AF-AB05-4898-80F7-2BE9A044EB4A@mbari.org> Hi Joachim, > There has been some discussions about the best way to install RXTX > and where to place files. > > I suggest that, > > - we include the native libraries for the most common operating > systems (in a special version of) RXTXcomm.jar > - we add loader code which tries to extract and load the platform > specific binary at runtime > - on failure the current mechanism remains as a fallback I like your suggestion. However, my understanding is that in general the native code needs to be on the PATH (Windows), LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (Mac OS X) in order for it to be able to be loaded by the JVM. The alternative is to point to your native lib directory using -Djava.library.path=/my/dir/with/native/libs when you launch the JVM. So, I'm very interested to know how you're planning to work around this. > PS: Of course the suggested solution is already possible today, > however relatively few programmers know how to correctly extract a > binary resource file via the class loader and load it as a native > library. So how do you use it to dynamically load a native lib? I've read that you can't really modify the java.library.path after the JVM has been launched. (http://forum.java.sun.com/thread.jspa? threadID=627890&tstart=90) Thanks Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060620/63d79fda/attachment-0070.html From joachim at buechse.de Tue Jun 20 09:20:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 20 Jun 2006 17:20:29 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x Message-ID: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> I have added most of the changes from the 2.1 branch to the 2.0 branch. This includes - correction of illegal javadoc comments - implementation errors in handling of Thread.interrupt in RXTXPort.java - MacOS X locking without lock files/special user groups - XCode project which builds a universal binary library - updated documentation for OSX I have done some minimal testing (only G4). [Trent: there are still some changes you made for specific baud rates. I will not sync this, as I can not test them. From my perspective we are ready for 2.08/2.18] The updated documentation can be found in the file README.OSX. Here it is: ------------------------ Required files ----------------------- To use or compile RXTX 2.0.x you need to downlad the "generic" version (2.0.3) of the javax.comm implementation from Sun. The zip you download contains an archive comm.jar which is required: - To compile RXTX you need to copy comm.jar to MACOSX_IDE/XCode/comm.jar - To run the app you will need comm.jar in the classpath or in {java.lib.path} ------------------------ Installation on MacOSX ----------------------- WARNING: Please read this section until the end. --- Preparation --- You may want to spare your users the burden of modifying the global VM installation. OSX has several different VM versions installed by default and regular users will be unable to figure out which version will load your application. If you provide the class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } and make sure, that it is present in the classpath before Suns "generic" comm.jar your users can skip the following step: Create a file named javax.comm.properties in the directory /System/Library/Frameworks/JavaVM.framework/Home/lib/ which contains (only) the following line (no leading space): Driver=gnu.io.RXTXCommDriver ---- The unsafe way of using RXTX on OS X: ---- RXTX can be installed by putting the files libSerial.jnilib RXTXcomm.jar comm.jar into the folder /Library/Java/Extensions This is NOT RECOMMENDED as it creates versioning conflicts among applications. However you may be forced to install it this way if an application was written for Windows or Linux, requires RXTX and you are not able to change its starter. ---- The safe way of using RXTX on OS X: ---- Make sure that you have no (older) version of RXTX installed in /Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar comm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required). ---- History ---- Up to version 2.0.7/2.1.7 RXTX used lockfiles on MacOSX. The creation of lockfiles required special permissions for the user executing an application based on RXTX. To simplify the setup RXTX came with an installer modifying group permissions and installing RXTX in the global location /Library/Java/Extensions. However this was prune to versioning conflicts and is no longer recommended. --------------------- Build instructions for OSX XCode ------------------- contributed by Joachim Buechse original version by Dmitry Markman System requirements for building: MacOSX 10.4 XCode 2.3 open MACOSX_IDE/XCode/LibSerialUniversal.xcodeproj choose libSerial.jnilib target build After the build you will find RXTXcomm.jar and libSerial.jnilib files in the directory build/Development. In case you can't find RXTXcomm.jar build the RXTXcomm target manually. In case of (serious) problems feel free to contact joachim at buechse.de . From tjarvi at qbang.org Tue Jun 20 22:01:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 Jun 2006 22:01:45 -0600 (MDT) Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: > --- > Preparation > --- > > You may want to spare your users the burden of modifying the global VM > installation. OSX has several different VM versions installed by > default and > regular users will be unable to figure out which version will load your > application. > > If you provide the class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > and make sure, that it is present in the classpath before Suns > "generic" comm.jar > your users can skip the following step: Hi Joachim With regards to the above, I have not seen that we have Sun's OK to promote that. I'm not very comfortable with the distribution documentation advocating this without Sun agreeing. I see your point but I'd rather not actively promote putting classes in Sun's namespace without permission if you don't mind. This isn't about what is in a license. I'll go through the code tomorrow night. It was a late night at work today. There is also a w32 fix comming for people opening and closing multiple ports. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Jun 21 01:56:45 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 21 Jun 2006 09:56:45 +0200 Subject: [Rxtx] 2.0x in sync with 2.1x In-Reply-To: References: <0540675F-BF3F-450A-BC48-CEED2CD11945@buechse.de> Message-ID: <789772A7-9A41-4861-BE2D-5240E2B4F0E0@buechse.de> Hello Trent, I guess we will not get an explicit OK from Sun for such a hack. I think Paul has made it pretty clear, that he does not have the resources to modify the 2.x or 3.x code for the needs of RXTX. I'm not thrilled but OK with the current API. Hence I dont agree with Paul's idea to start a new JSR to fix the implementation - but that's mainly because I dont have the time to push it. According to their Readme Sun sees no business case in having cross platform support for javax.comm - that is sad but it's none of my business. However I prefer to program versus javax.comm in my projects as this gives an advanced user the chance to exchange the provider without access to the code. I interpret Pauls reponse to my original "Request for comment" as a quiet acceptance of the hack I propose (he did respond, but not at all to the sun.comm namespace suggestion). This is certainly not something we should put into RXTXcomm.jar but hinting a work around for implementation errors should be allowed. That's why I've choosen the wording "You may want to spare" and "If you provide". The company I worked for has choosen similar hacks for years to fix bugs in swing for JDK1.1 applications. Those hacks were usually included in their own swingpatch.jar. Having said all that - I do not take it as an insult if you remove the paragraph from the Readme. I appreciate that you notified me before. It would be interesting to hear some more opinions from the list members... Best regards, Joachim On 21.06.2006, at 06:01, Trent Jarvi wrote: >> --- >> Preparation >> --- >> >> You may want to spare your users the burden of modifying the >> global VM >> installation. OSX has several different VM versions installed by >> default and >> regular users will be unable to figure out which version will load >> your >> application. >> >> If you provide the class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> and make sure, that it is present in the classpath before Suns >> "generic" comm.jar >> your users can